Fix paragraph indentation issue - #508

…covery testable (#599)

* Notion API: Cover indented paragraphs in the page fixture

A paragraph with has_children was not represented, so nothing caught the
children being dropped (#492). Two shapes are recorded: a parent with its
own text, and the empty parent Notion writes when a block is indented
under a blank line.

Checked against the bug: with #508 reverted the recording loses both
child lines and keeps only the parent, which is what users saw.

* Notion: Cover a database row's properties

The conversion turns a page's property table into frontmatter, reading it
through tbody.rows and tr.cells. linkedom implements neither, so the path
threw before it converted anything and no test could reach it - and no
committed export carries a property table to reach it with.

The shim supplies both, on Element because linkedom gives every element
the plain HTMLElement prototype. Measured rather than assumed: no
recorded output moves, and an Evernote table - the one place turndown's
GFM rules read .rows - converts byte for byte as before.

The page is hand-written to the export's shape, which it says, and a real
export with a database should replace it. Checked against the bug: with
#577 reverted the recording loses Price (BRL), Price (USD) and Discount
entirely, which is what #407 reported.

* Notion API: Let the live check find a page that has blocks

Without NOTION_PAGE_ID it read whichever page search returned first and
asserted that page had blocks. In a workspace whose first result is a
database row - which keeps its content in properties and has no blocks at
all - the check failed on the workspace rather than on the API, which is
the one thing it is not meant to report.

It now reads candidates until one has blocks, and says so plainly if none
does. Checked against a real workspace: it passes there, so the shapes
example-page.json is written to are the ones the API still returns.

* Notion API: Move page discovery off the importer

Turning a search response into the tree the picker draws needs nothing
from the vault or the network, but it sat on the importer where no test
could reach it - so diagnosing a report of a missing page meant
reimplementing the filtering in a scratch script and trusting that the
copy agreed with the original.

Moved as it stands. The two filter phases, extractItemTitle,
extractParentId and buildTree are the same code with this. instead of a
receiver, and NotionParent and NotionTreeNode move with them.

Checked against a real workspace of 1123 search results: same 1064 items
and same 7 roots, with the same children under each.

* Notion API: Record which pages the picker offers

The search response is the one input that decides whether a page can be
imported at all, and every report of a missing one - #590, #512 - is a
claim about what this drops. Nothing recorded what it keeps.

The fixture carries each object and parent combination seen in a real
workspace, including the two the reports turn on: a database that is
itself a top-level page, and one inline in a block. Recorded output is
the tree as an outline, so a page that stops being offered is a line that
moves.

A top-level database is offered today, which is what #590 says it is not.
The reporter's integration was connected to the database alone rather
than to the workspace, and that is the part still to reproduce.